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(57) Abstract: The invention 
relates to a system for providing 
user-specific in formation in 
a communications netwoiic. 
User profile data is stored in 
user-specific software agents, 
each agent comprising at least 
an inner layer for storing the 
user profile data and an outer 
layer for storing contracts. 
The contracts are used by the 
service applications residing 
in the network for obtaining 
user-specific information from 
the agents. An individual 
contract deternunes the items 
that the service application 
associated with that contract 
sees from the user-specific 
data and also how the service 
application can process said 
items. The current locations of 
the contracts are maintained in 
a separate location information 
system so that tlie location of a 
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USER PROFILE MANAGEMENT IN A COMMUNICATIONS NETWORK 
Field of the Invention 

The invention relates generally to provision of services in a communi- 
5 cations network. More specifically, the invention relates to a system for provid- 
ing user-specific information in a network where personalized services are 
provided. 

Background of the Invention 

10 The strong growth in the number of Intemet users and services pro- 

vided through the Internet has been one of the most remarkable phenomena 
in communications in recent years. The popularity of the Internet shows that 
people are eager to adapt technology to their lives. However, as the spectrum 
of services available on the Internet and their complexity increase, the task of 

15 gaining maximum value from the services becomes increasingly complicated. 
As a simple example, if a currently available Web search engine is given a 
simple query, thousands of pages of irrelevant material is normally obtained, 
which has to be browsed through manually. Another example can be taken 
from the telecommunications world. In the emerging open telecom market, the 

20 users will have the opportunity to buy affordable services matching their re- 
quirements and preferences. This may involve complicated decisions concern- 
ing the features of the customized sen/ices and the selection of the service 
provider, especially when the customer roams outside his/her home network. 
In order to maximize the gained utility, users have to get to know multiple 

25 providers, and enter into negotiations with them. Too often this is an insur- 
mountable task; users are overwhelmed with more alternatives or more infor- 
mation than they can easily handle. This growing complexity is partly due to 
the transformation of the traditional search engines into Web portals offering a 
broad array of services. 

30 In both of the above-mentioned cases, semi-intelligent techniques 

could be employed to automate the selection process. However, in order to 
achieve the desired goals, something has to be known about the user. This 
knowledge makes up the user profile. What the profile contains, depends on 
the particular service, but the ultimate goal could be seen as forming a 

35 metauser, a high-level description of the user. Service providers can then 
utilize this description in order to offer services adapted to each user. In other 
words, by means of these profiles the service providers can adapt the applica- 
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tions' behaviour to the users. The process of generating the user profiles, or 
learning to know the users, is called profiling. 

Profiling has become an important issue in solving the above prob- 
lems related to complex sen/ices and overwhelming information flow. This is 
5 because profiling enables personalization of the services, which in tum pro- 
vides customized aids to help individual users to cope with the above prob- 
lems. Personalization is the process of applying the knowledge in the user 
profile in order to provide results fitting the needs of a particular user. Today, 
many Web portals are moving in this direction by providing means for filtering 
1 0 the information content based on the Interests of the user. 

Although personalization is seen as a solution in overcoming the 
above problems, present technology is still immature, and there are many 
problems related to the existing systems. These are discussed briefly in the 
following. 

15 At present, users have to supply their profile data to each individual 

service provider. Therefore, a lot of resources are needed to create accurate 
profiles not only by the service providers, but also by the users. Beginning from 
the registration for a service, the users fill out numerous forms about their 
personal characteristics, and increasingly also about their preferences. From 

20 the initial information and observations during interaction with users, the ser- 
vices then form profiles of the users. Teaching every new service provider from 
scratch takes time and becomes a fnjstrating task for the user. Since the user 
has to input profile information for each service provider, the information relat- 
ing to a single user scatters all over the network, and different- sen/ice provid- 

25 ers have different kinds of information about the user. One drawback of this is 
that one profile cannot be used, at least not directly, by another service pro- 
vider. The management of the profiles also becomes a problem. For example 
updating an email address for every service easily becomes an insurmount- 
able task. Even if the facilities were provided by the services, recalling each of 

30 those who should be notified is hard. Thus, the users' capabilities and motiva- 
tion to maintain the profiles are poor, and the accuracy of the profiles is re- 
duced. 

A further problem related to having each service maintain its own 
profile on each user is that an individual sen/ice's view of the users is very 
35 limited. Therefore, the user cannot benefit from the service in the most efficient 
way. 

Another major problem relating to th^ present situation is the privacy 
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of the users. It is clear that the storage of personal data, such as the user 
profiles, in an open and shared systenn like the Internet requires careful con- 
sideration of user privacy. Since the users are, in the current situation, unable 
to comprehensively control the contents and the use of their profiles, the 
5 privacy of the users can easily be invaded. For example, an individual user has 
no means to prevent a malicious party from accessing the profile data on a 
single server or from combining the data on different servers. 

Some currently implemented systems that employ a user model 
operate locally in the user temiinal (e.g. a personal computer). One example of 

10 this kind of system is depicted in U.S. Patent 5,913,030, which describes a 
system for communications between a client system and a server communica- 
tively coupled to the client system. Information about a user is stored in the 
client system (i.e. in the client terminal). The user information comprises a 
plurality of attributes, each attribute comprising information relating to the user 

15 and a willingness indicator indicating the level of willingness of the user to 
reveal information concerning that attribute. The terminal can also include 
several persona modules, each containing data defining a particular persona 
of the user. The privacy of the user can further be protected by sending user- 
specific data to a trusted third party which reveals only aggregate demographic 

20 information about all the users to the server providing the service. The persona 
module can also be provided with a disguising function which generates incor- 
rect information about the user. 

The main drawback of the systems where the user profile resides in 
the user terminal is that the utilisation of the user model is restricted to that 

25 terminal, i.e. typically to a fixed place, and the dissemination of the items of the 
user model is restricted. 

Currently, there are also server-based systems which allow a user to 
use personalized Web services while providing privacy. One such service is 
ProxyMate (former Lucent Personalized Web Assistant, at 

30 www.proxymate.com). ProxyMate focuses on offering users the means to 
interact with multiple servers so that an individual server providing a specific 
service can not reverse-engineer the identity of the user, but at the same time 
the user can be recognized and authenticated on repeated visits. This is 
achieved via generation of secure, consistent and pseudonymous aliases for 

35 Web users, and by anonymizing traffic to the Web servers. ProxyMate also 
acts as a mediator for e-mail. 

An important design criterion behind ProxyMate has been stateless- 
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ness. It does not keep any long-tenn states, i.e. mappings between users and 
their aliases. Instead, all tlie aliases are generated on demand via a one-way 
function. 

ProxyMate works as a proxy for Web traffic. Hence, it can be located 
5 and used from anywhere in the network. These sen/er-based systems require 
trust from their users. Although their theoretical construction is such that they 
do not require any state to be maintained outside the session, the implementa- 
tion might, for example, collect a log of the user's actions. A further drawback 
of these served-based systems is that the user's connection to the server 

10 providing the service always goes through these proxy servers. This restricts 
the ways the desired data can be accessed. Further, constant routing through 
certain proxies results in inefficient use of the transmission resources of the 
network, and these proxies may become bottlenecks having an adverse effect 
on the response times of the services. 

15 It is an object of the invention to obtain a solution by means of which it 

is possible to alleviate or eliminate the drawbacks described above and to 
bring about a system which provides the users of the network with full and 
comprehensive control of their profiles. 

20 Summary of the Invention 

This and other objectives of the invention are accomplished in accor- 
dance with the principles of the present invention by providing a system in 
which the profile data relating to a single user is placed with a profile agent 
dedicated for the use of that user only. Thus, each user is provided with a 
25 profile agent by means of which he/she can control his/her digital identities, i.e. 
the identities that the service applications see as the user. In this way it is 
possible to provide, by means of a single profile agent, applicable profile 
information to a large number of services needing different kinds of profile 
information. 

30 Each user-specific profile agent has a multi-layer structure so that the 

user profile data can be accessed only through the uppermost layer compris- 
ing contracts which form the interfaces between the user-specific data and the 
network. The user-specific profile agents are accommodated in special serv- 
ers, which are in this context termed hostels, and the network further com- 

35 prises a lookup system from where the location of a certain contract can be 
queried. The service applications can access the user-specific data only 
through the contract after such a contract is made for this purpose. The con- 
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tract determines the information items that the service application sees from 
the user-specific data and also how the sen/ice can process said items. Each 
contract forms an interface of the user-specific data for a service or group of 
services. The contracts thus associate certain views or profiles with certain 
5 services. However, one service can also use more than one contract to access 
the user-specific data. In this case the service cannot recognize that the two 
contracts relate to the same user. 

In a preferred embodiment of the invention the user profile data are 
disseminated only via user-defined digital identities. These identities form a 

10 layer between the contracts, which form the outermost layer of a user profile 
agent, and the basic profile data, which form the innermost layer of a user 
profile agent The basic data can not be accessed by any service. The identi- 
ties, which are also called personae in this context, represent consistent views 
on the basic profile data of the user. The services see these views only, and 

15 they are unable to distinguish whether two different views belong to the same 
user or not. 

The privacy of the users thus has a central position in the system, 
since the user profile is centralized with an agent which can be controlled by 
the user, or by a party authorized by the user. Further, it is difficult to determine 
20 that two contracts are related and to expose the agent behind the contracts. 

Furthermore, as the profile agents can be mobile, they are no longer 
bound to certain providers, and the lifetime of the profiles becomes unlimited. 

Brief Description of the Drawings 

25 In the following, the invention and its preferred embodiments are 

described more closely referring to the examples shown in Figures 1 to 14 in 
the appended drawings, wherein: 

Figure 1 illustrates the architecture of the system according to the 
present invention, 

30 Figure 2 illustrates the general structure of an individual user-specific 

profile agent. 

Figure 3 illustrates the cooperation of a service application with the 
profile agent, 

Figure 4a illustrates a typical structure and information content of the 
35 lowermost layer of the user profile agent, 

Figure 4b illustrates a typical stmcture and content of an individual 
item inside the lowermost layer of the user profile agent. 
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Figure 5 illustrates an example of the contents of the towemnost layer 
of a user profile agent. 

Figure 6 and 7 are examples of the contents of two different personae 
on the middle layer of a user profile agent, 
5 Figures 8 and 9 are examples of the contents of two different con- 

tracts on the outermost layer of a user profile agent, 

Figure 10 illustrates an example of message transfer between the 
elements of the system when the user creates a profile agent for her- 
self/himself, 

10 Figure 11 illustrates an example of message transfer between the 

elements of the system when a contract is created for a sen/ice application. 

Figure 12 illustrates an example of message transfer between the 
elements of the system in conjunction with a general information request 
received by a user profile agent, 
15 Figure 13 illustrates an example of message transfer between the 

elements of the system when the user profile agent moves in the network, and 
Figure 14 depicts the structure of the lookup system. 

Detailed Description of tlie Invention 

20 Figure 1 shows the architecture of the general system according to 

the present invention. The system includes several servers (S1 to S3) which 
offer a broad array of resources and services for the users of the network. In 
this example, all the servers are nodes of the Internet or an Intranet network 
(or an equivalent TCP/IP network). In this context the term "service" refers to a 

25 service application residing in a server. 

User terminals (UT1 and UT2) have access to the sen/ice providing 
servers in a manner known as such. The user terminals can be fixed terminals, 
as shown in conjunction with terminal UT1, or mobile terminals that have 
wireless access to the system or to the network, as shown In conjunction with 

30 terminal UT2. Wireless access can be implemented through various access 
points (AP1) or alternatively through gateways (GW1) that translate the re- 
quests from the protocol stack used between the terminal and the gateway, 
such as the WAP protocol stack, to the protocol stack used between the gate- 
way and the server, i.e. to the WWW protocol stack (HTTP and TCP/IP). 

35 In temis of the inventive Idea, the types of the user terminals and the 

connections between the user terminals and the service providing servers are 
not of significance. In this context the only essential feature of the terminals is 
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that they are provided with browsers or other known client software by means 
of which they can communicate with the servers providing services. This 
communication occurs preferably according to HTTP protocol, although there 
can be a translating gateway between a server and a client terminal, as men- 
5 tioned above. 

The system further comprises user-specific profile agents PA so that 
each user of the system preferably has one profile agent assigned to that user 
only. A profile agent here refers to a piece of software that can accomplish 
tasks on behalf of its user and which stores the profile data related to the user. 
10 Thus, an individual profile agent is an integral entity to which the user can 
delegate the task of coordinating his/her profile. The stoicture of an individual 
profile agent, consisting of code and data, is discussed below in connection 
with Figures 2 and 3. The agents are implemented using known agent tech- 
nology. 

15 The profile agents are located in specific servers, called hostels in this 

context. A hostel is simply a platform (i.e. a piece of software) that offers an 
execution environment for the profile agents and a connection to the network. 
For simplicity, Figure 1 shows only one hostel HS, although there are typically 
many hostels in the network. 

20 The system further includes agent creation units AC, by means of 

which the users can create their profile agents. Agent creation units can reside 
in the user terminals or in conjunction with the hostels, for example. 

Each user-specific profile agent is controlled only by the user in ques- 
tion. Thus, in the system according to the present invention the user profile is 

25 centralized with an agent controlled by the user. A user-specific profile agent 
can be in a fixed location or it can be a mobile agent, especially if the user is 
mobile. A mobile profile agent preferably moves so that it is always in the 
hostel nearest to the current location of the user. 

To promote profile agent mobility the system further includes a lookup 

30 system LS which stores the current location of each individual profile agent 
and from which the locations of the profile agents can be queried. The struc- 
ture of the lookup system is discussed in more detail below, where it is de- 
picted that the location of each profile agent is stored as a plurality of locations, 
each location indicating the current address of the individual contract which is 

35 part of the profile agent. 

Figure 2 depicts the structure of an individual profile agent from the 
point of view of its clients. The agent preferably has a three-layer stoicture with 



wo 01/86494 



8 



PCT/FIOl/00430 



the user base profile forming the lowermost layer. The base profile typically 
includes all data about the user, said data being supplied by the user or the 
clients. The middle layer includes the different digital personae of the user. 
Each persona is formed from the data in the base profile and it is a certain 
5 view of the base profile, the view being defined by the user. An individual 
persona or view can be formed passively, i.e. it can consist of data units that 
fonn a subgroup of the data units in the core profile, or actively, i.e. the desired 
data units in the base profile can be processed to obtain the data units forming 
the persona. 

10 The topmost layer of the profile agent consists of interfaces which are 

here called contracts. Contracts are the interfaces through which the user and 
the services can access the profile agent. The user always accesses the 
profile agent through a special contract, called master contract, which is for the 
use of the user only. The service applications access the digital personae 

15 through service contracts, i.e. the sen/ices can only point to the contracts, not 
to the personae behind the contracts. To be able to access the profile data, 
each service must first make a contract with the profile agent. After a contract 
is made, the service can utilize the profile agent through the said contract 
(interface). Each agent typically includes one contract per service provider or 

20 service application, although one contract can be for a group of applica- 
tions/providers and one service application/provider can also use several 
contracts. 

Thus, the identity of the user is controlled by the contracts. While from 
the standpoint of the architecture the contracts mainly represent pseudony- 

25 mous contact points to the profile data, to the users their most important func- 
tion is to set the limits to the information that is available to the clients (i.e. to 
the services). The profile agent needs to allow transformation of the base 
profile items from views to a base profile, and vice versa. The transformations 
usually needed are quite simple, such as replacing a name with an alias and 

30 emphasizing different interest areas of the user. A transfomnation from the 
base profile is made for a certain context. Generally, transformation is made 
for all valuations of the dimensions - who, where, when and what. These 
dimensions could be modeled as independent, so that the transformation 
could be the sum of transformations for all dimensions. In effect, the user could 

35 be represented by a base profile, and sets of transformations for each dimen- 
sion. By selecting a suitable set for each dimension, and layering these upon 
the base profile, strong expressiveness with respect to the context can be 
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achieved. 

Figure 3 illustrates the cx)operation of a profile agent with a service 
application. Each contract CT on the uppermost layer handles access rights 
controlling both the entities who can access the profile agent and what those 
5 entities are allowed to do if access is allowed. The personae of the user, in 
turn, corresponds to the views of the user available to the service applications. 
The views are formed from the base profile of the user, either directly or 
through transformations. 

Maintaining a broad spectrum of transformation sets is outside the 

10 user's capabilities. On the other extreme, total lack of transformations is not to 
be preferred either. Thus, the user profile agent is preferably based on a 
compromise of these two, i.e. the user fixes the transformation to some con- 
text. In effect, the transformation defines a persona of the user - e.g. a home 
or business persona. Furthermore, the personae are separated into their own 

1 5 layer, so that they can be used in multiple contracts and so that one contract 
can allow the use of multiple personae. 

The base profile contains the user's whole profile organized in a 
hierarchical manner. Figure 4a illustrates an example of a base profile organ- 
ized in different categories by the content of the profile. In this example, the 

20 first category includes the unique identifiers of the user, the second category 
biographic and demographic data about the user, the third category the ad- 
dresses of the user, the fourth category data about the interests and attitudes 
of the user, etc., and the last category data about the current location and 
activity of the user. 

25 Each category in the base profile includes a plurality of items. Figure 

4b illustrates an example of the structure of an individual item. The content of 
an item is divided into data units describing the item. In the example of Figure 
4b, the first data unit represents the name of the item, the second gives a 
description of the item, the third indicates the type of the item, the fourth de- 

30 scribes how the item is transfonned for a persona of the user, and the last one 
includes the value of the item. By making the items separately addressable, 
the user can control the access to individual items. As is obvious, the number 
and type of items in an individual category can vary, depending on the cate- 
gory and on the user, for example. The number of hierarchy levels in the base 

35 " profile can also vary. 

Figure 5 illustrates an example of the contents of one base profile 
forming the lowermost layer of an agent. In the figure, the categories or items 
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at the same hierarchy level have been indicated with bullets that are white at 
every other level and black at every other level. In this example, the user is 
Joe Doe, whose nickname is "Foobar". In the base profile, the "transformation" 
field describes all the transformations that are possible for that item. For ex- 
5 ample, the gender of the user can be switched between male (M), female (F), 
and neutral (N). In the model/preferences category, different service providers 
can gather information about the user preferences. In this example, the said 
category includes relative values indicating how frequently the user uses the 
sports, business, and weather services provided by the service portal at 

1 0 www.companyl .com. If a certain agreed ontology is used for user preferences, 
all service providers can utilize this information for their purposes. 

In practice, the base profile normally includes much more Information 
than in the example of Figure 5, which only illustrates what kind of data the 
base profile can include. 

15 Figures 6 and 7 show two examples of the personae of the user 

whose base profile is shown in Figure 5. Figure 6 illustrates a business per- 
sona which can be used during office hours, for example. In this persona, the 
above-mentioned business channel at www.companyl .com gets more weight 
than the other services, i.e. this persona is more interested in the business 

20 channel than in the other services. Moreover, the nickname of the user is 
masked from the services, i.e. the services do not see the nickname of the 
user. Figure 7 illustrates a second persona, here called an online persona, 
which can be used in sessions initiated from home, for example. For this 
persona, the gender of the user is changed to neutral, the income value is 

25 rounded to the nearest 10000, all the items in the name category, except the 
nickname, and also all the items under the home address are hidden. 

Figures 8 and 9 illustrate the contents of the contracts on the outer- 
most layer of the user profile agent. Figure 8 shows a master contract which is 
used by the user only. To enable secure communication with the user, the 

30 master contract stores the public key of the client (PKU01 ) and public and 
secret keys of its own (PKM01 and SKM01). The client of the master contract 
is always the user whose master contract is in question. Figure 9 shows an 
example of a general contract for a service which is here marked as "ser- 
viceOI". Through this contract, two services can access the user profile data, 

35 i.e. services with the public keys PKS01 and PKS02. The contract can define 
the items of the base profile that can be accessed through the contract (cf. 
access rights/type=allow). In this example, the items in the model/preferences 
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category can be read and written, whereas the items in the identifiers category 
and under properties/income can only be read. The contract can also define 
the Items of the base profile that are not allowed to access through the con- 
tract. In this example, the postal address categories can not be accessed at all 
5 (access rights/type=deny). 

The contract can further determine the personae (views) that can be 
seen through this contract. In this example, only the online persona can be 
seen through the contract. Thus, even if the user is currently using the busi- 
ness persona, serviced would see the online persona. The contract can also 

10 determine different policies for different services. The contract of Figure 9 
includes one policy: if the recipient, i.e. the sen/ice provider, is "companyOr, 
indicating that the items are for its use only, all the items can be accessed 
which are not masked or othenA^ise hidden. As discussed below, the user 
controls what items can be seen through the contract, and in which form the 

15 items can be seen. In the contracts, the standard format according to P3P (the 
Platform for Privacy Preferences Projects) can be used to inform the service 
provider of the privacy practices adopted by the profile agent (i.e. the user). 

In this way the contract further defines the views on the middle layer 
of the agent. The agent can also include several middle layers, each manipu- 

20 lating the view on the preceding layer. Determination of the data available to a 
client is preferably done so that the definition of the set of data available to a 
client gets more accurate and detailed moving from the base profile towards 
the outermost layer of the agent. 

Each user profile agent is preferably created by the user in question. 

25 Figure 10 illustrates an example of message transfer between the elements of 
the system when the user creates a profile agent for himself/herself. For the 
creation of an agent the system according to the present Invention includes the 
above-mentioned agent creation units. Each agent creation unit is a piece of 
software that allows the user to create a user profile agent. The agent creation 

30 units can reside in the user terminals, in conjunction with the hostels, or in 
separate Web sites offering this service for the users. The messages ex- 
changed are preferably always encrypted when the public key of the opposite 
party is available. 

Initially, the user terminal sends the agent creation unit a message 
35 requesting the said unit to initiate the creation of a user profile agent (step 
1001). This message includes the public key (P_KEY_U) of the user. In re- 
sponse to this message, the agent creation unit generates an empty profile 
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agent for the user. When this has been accomplished, the agent creation unit 
requests the profile agent to create a master contract to allow the user to 
manipulate the agent through the said contract (step 1003). This request also 
includes the public key of the user. The user profile agent then generates an 
5 identifier (CID) for the master contract (step 1004) and a key pair for the mas- 
ter contract. The master contract now has the keys shown in Figure 8 for 
encrypted communication with the user The user profile agent then informs 
the agent creation unit about the new contract by sending the creation unit an 
export message including the identifier and the public key (P_KEY_MC) of the 

10 newly created contract (step 1006). In response to this message the agent 
creation unit sends the lookup system a registration request (step 1007). This 
. request includes the identifier and the public key of the master contract as well 
as routing information pointing to the location of the profile agent However, the 
routing information in this example is null (empty), since the user profile agent 

1 5 has not yet been moved to its correct location in the network. Upon receiving 
this message, the lookup system checks that the identifier is not being used by 
any existing contract. If the identifier is not in use, the lookup system registers 
the contract and sends an acknowledgment to the agent creation unit (step 
1008). 

20 After this the user profile agent is moved to its correct location, i.e. to 

a hostel (step 1 009). If the agent creation unit and the profile agent are already 
in a hostel, this step is naturally omitted. The migration of the agent typically 
includes several messages, although only one is shown in the figure. 

After migration, the identifier of the contract is re-exported to the 

25 lookup system with proper routing information pointing to the hostel (step 
1010). This is performed so that the hostel first activates the agent. As a result 
of this, the agent asks the hostel to perform the re-export, and the hostel 
sends the message to the lookup system. The agent creation unit then ac- 
knowledges the creation of the master contract to the user at step 1011. This 

30 acknowledgment message includes the identifier and the public key of the 
master contract. The user profile agent is now fully usable, although rt is still 
empty. 

The user then has to supply data to the user profile agent. For this 
purpose, the user terminal first requests the routing information of the profile 
35 agent from the lookup system by sending a request including the identifier of 
the master contract (step 1012). Having received the routing Information point- 
ing to the hostel in which the user profile agent resides, an update message is 
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sent to the hostel at step 1014. This message includes the identifier of the 
master cx>ntract, the operations to be performed, and the data to be used by 
the operations. The hostel fonwards the message to the profile agent. For 
example, if the user has created a base profile according to Figure 5, the 
5 message would contain the following write operations and data: 

update("ldentifiers/name/first", "John") 

update("ldentifiers/name/middle", "Bar") 

update("ldentifiers/name/lasf, "Doe") 

update("ldentifiers/name/nickname", "Foobar"), etc. 
10 Thus, the user sets the desired data in the profile agent through the 

master contract whose address is first retrieved from the lookup system. This 
may require that several update messages are sent to the hostel. 

After the profile agent has performed the desired operations, it ac- 
knowledges the operations (step 1017) to the hostel, which forwards the 
1 5 acknowledgment to the user terminal (step 1018). 

The user profile agent is now ready for the service applications. If the 
user later wants to update his/her existing profile agent, the update occurs as 
in steps 1012 to 1018 in Figure 10, i.e. routing information pointing to the 
correct hostel is first requested from the lookup system, and then one or more 
20 update messages are sent to the hostel where the profile agent resides. 

When the user contacts a service that wants to utilize the profile data, 
a contract must first be made for the sen/ice. Figure 1 1 illustrates an example 
of message transfer between the elements of the system when a new contract 
is created between the user profile agent and the client (i.e. the service pro- 
25 vider/application). First, the user sends a conventional service request to a 
Web site (step 1101) providing services. In response to the service request the 
user typically receives a registration page from the server (step 1102). After 
this, the user has to access his/her profile agent. For this purpose, he/she then 
sends the lookup system an import message requesting the address of the 
30 master contract from the lookup system (step 1103). In response to the mes- 
sage, the lookup system returns routing information to the user, the routing 
information indicating the current location of the master contract. In this exam- 
ple it is assumed that the user profile agent is currently in hostel A. 

The user then sends a message to hostel A (step 1 105), requesting a 
35 generation of a contract for the service. This message includes at least the 
identifier of the master contract as well as the public key of the service 
(P_KEY__S) which has been received earlier in connection with the registration 
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page. The hostel finds the user profile agent corresponding to the master 
contract ID received and fonA^ards the message to the said profile agent at 
step 1106. In response to the message, the user profile agent then generates 
a contract ID and a key pair for the service (step 1 107), and the agent exports 
5 the generated contract ID (CID) and its public key (P_KEY_C) to the hostel 
(step 1108), The hostel knows what node of the lookup system is available 
and sends a request to this node at step 1109. This request asks the lookup 
system to register the new contract. The message includes the ID of the con- 
tract, the public key of the contract, and routing information pointing to hostel 
10 A. The routing information given in this message indicates a different route to 
hostel A as compared to the route given at step 1104, so that the master 
contract and the service contract cannot be linked together by means of their 
location. 

If the registration of the new contract was successful, the lookup 
15 system acknowledges the operation to the hostel (step 1110), which further 
acknowledges it to the user profile agent (step 1111). 

After this, the user is informed of the ID of the newly generated con- 
tract. The user profile agent first sends the ID and the public key of the con- 
tract to the hostel, which fonwards the message to the user temninal (steps 
20 1112 and 1113). 

When receiving this information, the user terminal updates the con-r 
tract according to his/her preferences at step 1 1 14. In other words, at this step 
the user determines the views that can be seen through this contract by defin- 
ing at least the outermost layer of the profile agent. This step determines what 
25 items the service provider/application can see, and in which form, and what the 
service provider is allowed to do with the contract. 

After this, the user terminal sends the server providing the service a 
reply to the registration page received at step 1102. This message at step 
1115 can be a normal HTTP-POST message including the contract ID and the 
30 public key of the contract. 

As described above, in this basic scenario the user initiates the rela- 
tionship between the service and the user profile agent by sending the identi- 
fier of the new contract to the server providing the service. In response to this 
message, the server requests routing information to the hostel of the agent 
35 from the lookup system (step 1116). When the server receives this infomiation 
at step 1117, it knows that a contract exists, i.e. that the user is not trying to 
bluff. The server then requests information from the user profile agent by 
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sending an infonnation request to the hostel, which fonwards the request to the 
profile agent (steps 11 18 and 1119). The request Includes the ID of the con- 
tract, the operations, and the arguments relating to the operations. For exam- 
ple, If the server asks for the data that is under the sub-category "name" in the 
5 user profile, the operation is "read" and the arguments include "identifi- 
ers/name". 

The user profile agent first authenticates the request and then proc- 
esses it. In response, the required information is returned to the server (steps 
1121 and 1122). If a contract according to Figure 9 was created earlier, the 

10 user profile agent notices at step 1 120 that the online persona must be used. 
Since the online persona is such that under the sub-category "Identifi- 
ers/name" only the nickname can be shown, the user profile agent returns only 
the nickname (Foobar) at step 1121. When the server receives this message, 
it can continue its normal operation by welcoming the user to the Web site 

15 (step 1123). This HTTP response then includes the nickname of the user in 
the body of the message. After this, the user can use the service. 

If the service wants additional information about the user later in 
connection with the same or a subsequent service session, the service sends 
a request for information to the user profile agent. Figure 12 illustrates an 

20 example of message transfer between the elements of the system in conjunc- 
tion with such a general information request coming from the server providing 
the sen/ice. The server again first requests routing information to the hostel of 
the profile agent from the lookup system and upon receiving it sends the 
information request to the hostel (steps 1201 to 1203), which forwards the 

25 request to the user profile agent (step 1204). In this connection, it is possible to 
define that if the operation requested by the service is such that it is not al- 
lowed, permission is requested from the user terminal. The user profile agent 
then asks for permission from the user terminal by sending a verification re- 
quest to the user terminal via the hostel (step 1205). If the user allows the 

30 operation, it returns an acceptance (step 1206). When the user profile agent 
receives this message, it starts to process the request and then sends the 
desired information to the service (steps 1207 and 1208). For example, if the 
requested operation was *SA/rite", the user profile agent returns the status of the 
request (i.e. request accomplished). Should the user terminal deny the opera- 

35 tion required by the service, the service is informed that the operation re- 
quested is non-allowable. On the other hand, if no verification of the operation 
is required, the user profile agent replies the sen/ice directly after the request. 



wo 01/86494 



16 



PCT/FIOl/00430 



As mentioned above, the user profile agent can also move in the 
network. For example, if the current location of the user has been updated by 
an entity, such as a GPS receiver, the user profile agent can notice that it is 
too far away from the current location of the user. The user profile agent then 
5 initiates a location update by sending the current hostel a migration request, 
see Figure 13, step 1301. This message can include the address of the new 
hostel located near the current location of the user terminal, or, if the user 
profile agent does not know the nearest hostel, the message includes the 
cunrent location of the user together with a request to move the agent to the 

10 hostel nearest to said location. As a result, the new hostel (hostel B) is sent a 
request to accept the user profile agent (step 1 302). If the new hostel accepts 
the profile agent, it sends an acknowledgment to the current hostel (step 
1303). Upon receiving this message, the current hostel asks the user profile 
agent to serialize itself (step 1304). In response to this, the agent is transferred 

15 in serialized format to the new hostel (steps 1305 and 1306). This new hostel 
then activates the user profile agent at step 1307. In response to the activa- 
tion, the user profile agent sends the new hostel a location update request for 
each of the contracts, one contract at a time. Figure 13 Illustrates the location 
update of two contracts {C\D^ and CID2, steps 1308 and 1312, respectively). 

20 The messages sent by the user profile agent include the identifier and the 
public key of the contract. In response to each request from the user profile 
agent, the new hostel sends the lookup system an update request inserting 
routing information into the message (steps 1309 and 1313 for the first and 
second contract, respectively). The lookup system updates the location of the 

25 contract indicated in the request and sends an acknowledgment back the to 
the hostel (steps 1310 and 1314), which fonwards the acknowledgment to the 
user pnDfile agent (steps 1311 and 1315). When the user profile agent has 
received an acknowledgment from each update process, it sends the new 
hostel an acknowledgment request (step 1316). In response to this message, 

30 the new hostel acknowledges the transfer of the agent to the original hostel 
(step 1317). 

In this way the new hostel updates the location of the user profile 
agent contract by contract. The locations are updated one contract at a time in 
order to prevent the lookup system from detecting that the contracts belong to 
35 the same user profile agent. 

The lookup system operates like a black box in serving the rest of the 
system. The contact points (i.e. the contracts) are registered there, via a loca- 
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tion update operation, and are requested from there, via a lookup operation. 
Additional requirements for the lookup system are that it should be efficient 
and scalable. Thus, the capabilities of the lookup system should not hinder the 
mobility of the user profile agents. The options for implementing the lookup 
5 system are discussed briefly in the following. 

As the profile agent knows its clients, the simplest choice would be for 
the profile agent to keep the clients aware of its whereabouts. However, 
through collaboration the clients could observe when each pseudonym (per- 
sona) changes its location, and thus could correlate which pseudonyms are 

10 likely to be linked to the same person. In particular, this would prevent the 
users from having two contracts with a client. 

Utilizing fonvarding chains is another option for the implementation of 
the lookup system. In this solution the agent leaves a fonyvarding address at its 
previous hostel when it migrates to a new hostel. By following the resulting 

15 chain of forwarding addresses, a client can then find the agent. The drawback 
of this approach is that it performs poorly in situations where the agents are 
highly mobile - the length of the chain grows, and the search path might 
bounce from one side of the globe to the other. 

The home-based approach eliminates the erratic search paths In the 

20 forwarding chain approach. In the home-based approach, each user profile 
agent would have a designated server - home - to keep track of its location. 
However, this approach limits mobility, binding the user to its home provider. 

The name server approach is a traditional way to link identifiers to 
their locations. It is employed, for example in the Internet's Domain Name 

25 System. Name server systems are highly scalable, as the parts of the identifier 
space are distributed hierarchically over different servers. Unfortunately, hier- 
archical addressing assumes that address binding is relatively stable. 

To maximize personal mobility, the addressing must be flat, and the 
name server approach is not possible. A location service that is based on a flat 

30 address space is described in an article by Ballintijn, van Steen, and Ta- 
nenbaum: Exploiting Location Awareness for Scalable Location-Independent 
Object Ids, Proceedings of Fifth Annual ASCI Conference, Heijen, Nether- 
lands, June, 1999, pp. 321-332 (also available at 
http://www.cs.vu.nl/pub/papers/globe/IR-459.99.pdf, visited 4/2000). The 

35 lookup system according to the present invention is preferably according to the 
system described in this article. A central notion in this location service is the 
exploitation of locality, meaning that the cost of a lookup increases with the 
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distance to that address - i.e. it is cheaper to find local objects. 

The structure of such a lookup system is illustrated in Figure 14. The 
basic architecture is hierarchical so that the nodes of the system divide the 
network into a hierarchy of geographical domains. At the bottom of the hierar- 
5 chy are the leaf nodes, each leaf node covering a leaf domain which may in 
practice cover an area of a few LANs. The next higher level domain may then 
represent the city where the LANs are, for example. Associated with every 
domain is a directory node, which stores location information for the contracts 
within its domain (i.e. the domain covered by the nodes below It). The root 

1 0 node at the top of the hierarchy covers the whole network and contains point- 
ers for each identifier to the node in the next level, and so on. The leaf nodes 
store the addresses of the contracts. Thus, only one leaf node knows in which 
hostel the contract resides. When a lookup takes place, the lookup operation is 
started from the leaf node corresponding to the domain where the client is. If 

15 the leaf node has the address, the client gets the address immediately. Other- 
wise the request is propagated upwards until it reaches a directory node con- 
taining a record of the searched identifier, from where it propagates down- 
wards to the leaf node where the address is. 

As the structure and operation of the lookup system is known as such, 

20 it is not discussed in more detail in this context. More information can be found 
from the above-described article or from an article by M. van Steen and F. 
Hauck: Algorithmic Design of the Globe Wide-Area Location Service, The 
Computer Journal, 1998, Vol. 41, No. 5, pp. 297-310 (also available at 
http://www.cs.vu.nl/pub/papers/globe/lR-459.99.pdf). 

25 Although the invention was described above with reference to the 

examples shown in the appended drawings, it is obvious that the invention is 
not limited to these, but it may be modified by those skilled In the art without 
departing from the scope and spirit of the invention. The following describes 
briefly some possible variations. 

30 The system can support three different communication modes with 

the profile agents: stateless, session-based, and event-based modes. 

In the above-described stateless communication mode no long-term 
information about the location of the profile agent is kept outside the lookup 
system. This mode enables a simple request-response message exchange. 

35 Since the other modes pose security risks, stateless communication is the 
preferred way of communication for the majority of the clients. For each mes- 
sage exchange, the clients first lookup the location of the profile agent and 
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then perform the message exchange, including the authentication. 

A session-based communication mode enables the clients to com- 
mence a long-tenm relation with the profile agent. Should the profile agent 
migrate during this period, the session is also migrated. Furthermore, authenti- 
5 cation and policy notification are performed only once. However, when the 
profile agent sends notification of the new address to the clients, they can 
engage in a correlation attack based on the arrival time of the updates. Thus, 
the use of session based communication should be limited to trusted clients 
only. 

10 Event-based communication can be used for distributing changes in 

the profile. In this mode the clients subscribe to receive notification of certain 
items. When the profile agent receives an update on an item, it sends notifica- 
tion to all subscribers of that item. 

Events can also be utilized in correlation attacks. However, the poten- 

15 tial can be reduced by making their delivery more asynchronous, e.g. by insert- 
ing varying delays between each notification to be sent. 

The user profile agent can also be a distributed object comprising a 
mother agent and several child agents. Thus, different contracts can reside in 
different hostels. The benefit of this implementation would be that the user no 

20 longer has to trust a single hostel with all information, except for the hostel of 
the mother agent, which can still access all parts of the profile but no longer 
knows all the clients with whom the profile agent has a relationship. 

The profile agents can also be implemented without storing the views 
for subsequent information requests. In this case a view is formed by the 

25 profile agent each fime profile information is requested, using one or more 
functions determining the view. In this case the said one or more functions 
form the middle layer of the agent, residing between the core and the con- 
tracts. In its simplest form a contract can thus include its identifier only. 

However, using the approach described above is preferable, since it 

30 is much less complicated to define and utilize ready-made views than to gen- 
erate the views in real time. Furthermore, by means of ready-made views the 
service level can easily be improved. For example, the system can utilize 
ready-made views which are taken into use according to the time of day or 
according to the location of the user. 

35 In order to constrain the maximum number of contracts, a contract 

can be deleted after it has not been used for a certain time period. 

It is also possible to use the system as a "stripped" version so that the 
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same profile information, supplied by the user through the master contract, Is 
available to all clients that are allowed to access the profile information through 
the contracts. 

Anonymous routing can also be utilized for preventing malicious 
5 parties from exposing the user agent by correlating the contracts. In this em- 
bodiment a different address is attached to each contract of a user agent 
through the anonymizing network to which the hostels are connected. Since 
anonymous routing is known as such, it is not discussed in more detail here. 

Although the invention was described above with reference to the 
10 examples shown in the appended drawings, it is obvious that the invention is 
not limited to these, but it may be modified by those skilled in the art without 
departing from the scope and spirit of the invention. 
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Claims 

1. A method for providing user-specific information for tlie use of 
service applications in a communications network, the method comprising the 
steps of 

5 - storing user profile data in user-specific software agents, each agent 

comprising at least an inner layer for storing the user profile data and an outer 
layer for storing contracts which form interfaces for controlling the use of the 
user profile data from the network, the profile data being accessible through 
the contracts, 
10 - storing said agents in the network, 

- making contracts for the use of clients and storing said contracts on 
the outer layer, each client being an entity utilizing the user profile data in the 
network, 

- maintaining current locations of the contracts in a location informa- 
15 tion system, 

- requesting the location of a desired contract from said system, and 

- transferring user-specific information between the client and the 
agent through said contract. 

2. A method according to claim 1, further comprising the step of 
20 determining views of the profile data and associating each view with at least 

one contract, the view defining the form and content of the user-specific infor- 
mation available to the client through the contract with which the view is asso- 
ciated. 

3. A method according to claim 2, wherein the step of making con- 
25 tracts includes making a separate master contract for the use of the user only, 

and at least one service contract for the use of a service application residing in 
the network. 

4. A method according to claim 2, wherein said transferring step 
includes transferring user-specific information from said location to the client; 

30 whereby said information conforms to a view associated with said contract. 

5. A method according to claim 3, wherein said transferring step 
includes transferring user-specific information from the user to said location. 

6. A method according to claim 5, wherein user-specific infomnation is 
supplied by the user to the inner layer through the master contract. 

35 7. A method according to claim 3, wherein making a service contract 

is initiated by the user. 

8. A method according to claim 4, further including the step of storing 
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the views of the profile data in the agent. 

9. A method according to claim 8, wherein the step of transferring 
user-specific information includes using a view previously stored in the agent. 

10. A method according to claim 1, further comprising the step of 
5 transferring the agents in the network in response to a change in the location 

of the user. 

1 1 . A method according to claim 1 . wherein the step of transferring 
user-specific information includes encryption of the information. 

12. A method according to claim 3, wherein the step of requesting the 
10 location is performed at least once for each service session between the user 

and the client. 

13. A method according to claim 1, wherein In client is a service 
application. 

14. A method according to claim 1 , wherein the client is the user. 

15 15. A system for providing user-specific information for the use of the 

service applications in a communications network, the system comprising 

- user-specific software agents for storing user profile data, each 
software agent comprising at least an inner layer for storing said profile data 
and an outer layer for storing contracts through which the profile data can be 

20 accessed by clients, each contract forming an interface for controlling the use 
of the user profile data from the network and each client being an entity utiliz- 
ing user profile data in the network, 

- storage means for storing said agents in the network, 

- location management means for maintaining the current locations of 
25 the contracts, and 

- means for transferring user-specific information through said con- 
tract between the cun^ent location of a desired contract and a client. 

16. A system according to claim 13, further comprising means for 
determining views of the profile data and associating each view with at least 

30 one contract, each view specifying the form and content of the user-specific 
information available through the contract with which the view is associated. 

17. A system according to claim 14, wherein the user-specific soft- 
ware agents further comprise a middle layer for storing the views, said middle 
layer being between the outer and inner layers. 

35 18. A system according to claim 13, wherein the user-specific soft- 

ware agents are mobile agents. 

19. A system according to claim 13, further comprising agent genera- 
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tion means for creating a user profile agent. 
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